We recently had a contribution to the Go SDK to add this API, and I realized it would be useful to have it here in the Rust SDK now for integration with the query engine. So, this PR introduces a new API: ContainerClient::get_feed_ranges which returns a Vec<FeedRange> which describes the current physical partition layout. Like in other SDKs, FeedRanges map on to Partition Key Range IDs, but we don't expose the actual range IDs to the user, so that when a user specifies FeedRanges somewhere, we can adapt the ranges to the current partition topology (adjusting based on merges/splits, etc.).

Internally, we also have a ContainerClient::get_partition_key_ranges which uses the /pkranges REST API to fetch the full Partition Key Range metadata. This is used in the query engine, which already has to be updated with merge/split awareness and needs the exact PKRangeID for issuing queries. This API isn't part of the public surface area.

The model type returned by get_partition_key_ranges is PartitionKeyRange and that struct is part of the public surface area. It has to be in order to put it on the QueryEngine abstraction. But there's no way, using our public APIs, for a user to get the actual PK Range IDs from the REST API, nor do any of our APIs accept PartitionKeyRange objects. With a little bit of #[cfg] fiddling, I may actually be able to make it so these APIs are only public in the preview_query_engine feature, which is the only place we actually need them to be exported outside the crate.

This PR also adjusts the QueryEngine API to take the Partition Key Ranges as objects, since now the Rust SDK itself has the model and APIs to deserialize them. Before, it was passing the PKRanges as raw JSON and the query engine did the deserializing. This just removes some code duplication. I'll update the query engine to fix this shortly.